Support for integrated wlan hotspot clients

ABSTRACT

The invention proposes a method and a network device comprising an operation entity ( 3 ) for handling network connection and at least one access client entity ( 1, 2 ) providing connection handling to a specific network access device, wherein the operation entity is adapted to identify a need for a network connection and to inform the access client entity, and the at least one access client entity is adapted to perform an authentication. Hence, an authentication procedure is delegated to a separate entity so that depending on the specification of a specific network connection, a suitable access entity for performing the authentication can be selected.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to a method and a network device for handling anetwork connection, wherein an access client entity and an operationentity of the network device can co-operate.

2. Description of the Related Art

The invention is in particular related to WLAN (Wireless Local AreaNetwork) Hotspot Clients, although it is not limited thereon.

WLAN (Wi-Fi) has a large deployed base in enterprises, homes and inhotspots. There has been a business model developed around the use ofpublic access Wi-Fi; with service providers providing either time basedcharging or subscription based charging. This industry is still in itsinfancy, with many players competing for position. There are a number ofproprietary mechanisms deployed for enabling provider authorization andauthentication of users within a hotspot.

Many hotspot operators are small, and in general the operators have veryheterogeneous equipment. The service is very typically based on the“old” IEEE 802.11b standard. Most hotspots do not support the newsecurity standards (IEEE 802.1x or WiFi Protected Access), or the newphysical layer standards such as the fast IEEE 802.11g or the 5 GHz IEEE802.11a. Therefore, WLAN aggregators (companies which provide brokeringand aggregation for many different hotspot deployments) generally tendto concentrate on very simple equipment and HTTP-based (browser based)access control. In practice, this means users need to start a webbrowser, and browse to a web page. The hotspot captures their trafficand redirects them to a centralized login page, where the user will needto present the proper credentials for gaining access in the hotspot.

Many WLAN aggregators and hotspot operators have developed proprietaryautomated logon clients, by which the user can discover the hotspot andlog in easily, usually with one click. The hotspot clients arestand-alone networking applications, and the authentication protocol ismost often based on IP-layer protocols such as HTTP, TLS, XML, and noton IEEE standards.

The main logical functions of a Wi-Fi hotspot client are summarizedhere.

Many hotspot clients include a directory tool that can be used off-line,for example before a business trip, to list hotspots per location, sothat user can find out the nearest compatible Wi-Fi hotspot. Theinformation in the directory can be regularly updated, and it mayinclude maps and images of the location.

The hotspot client usually includes a WLAN Sniffer, which shows locallyavailable WLAN networks. At least the network name (SSID (Service SetIDentifier)) and the signal strength are displayed. Possibly, thesniffer can show richer information in addition to SSID, such as whetherthis is a “Sonera Homerun” network—or even hide the technical SSIDparameter from the user completely. In the existing Windows and PocketPC solutions, the WiFi sniffer tool can usually be used in manualnetwork selection—to select the network to join. The user can also usethe sniffer to manage SSID lists, network priorities, or otherconnection settings of the provider for automatic network selection.There is usually a “Connect” button, by which the user can launch theautomated log-on protocol. The WLAN sniffer, when combined with thedirectory tool enables users to quickly know which hotspots they haveaccess to, via their WLAN subscription.

The third feature of current WiFi clients is the actual logon client. Itprovides for easy authentication, so that the user does not need to usethe browser. Username, realm and password (or other credentials) arestored in the device. In cases when Network Access Identifier decorationis required, it is automatically applied. For compatibility with legacy802.11b-only networks, the logon protocol is typically an IP-basedautomated variant of web browser login.

Current hotspot clients are stand-alone applications, which the usermust explicitly launch.

In the following, some more sophisticated approaches are described, inparticular with respect to Symbian WLAN Networking and Seamless Roaming.

In Nokia's WLAN phones, WLAN settings can be included in Internet AccessPoint settings. The Internet Access Point setting can contain a SSID, orin the future, a list of SSIDs. The connection monitor, bearer managerand mobility policy manager components constantly try to detect, whichInternet Access Points are currently available. It is also possible tolearn, which SSIDs are available in the current neighborhood. For WLANInternet Access Points, the availability is based on WLAN scanning andthe SSID settings of each WLAN Internet Access Point.

Internet Access Points that provide connectivity to the same targetnetwork, such as the office intranet or the public Internet, can begrouped into a service network. The Internet Access Points can be givenpriorities, so that when opening a connection to a certain servicenetwork, the middleware can automatically select the most preferredavailable Internet Access Point. In the Nokia platform, when creating aconnection, the application may use the RConnection API (ApplicationProgramming Interface) to open the connection to a certain servicenetwork. Once the connection has been successfully established, theapplication can start using it.

When the user wants to perform a task, such as send an e-mail message,with a Nokia mobile device, the user can usually directly launch theappropriate application, such as the e-mail client. When the e-mailclient needs a connection to the Internet, the system will establish theconnection. The e-mail client may be pre-configured with the correctconnection information, or the user may be prompted to select theconnection among a list of available connections. Even when a VirtualPrivate Network (VPN) connection to a private network is required, thesystem will automatically establish the VPN connection. Hence, the userdoes not need to switch on any radios or VPN clients before launchingthe e-mail application.

A problem with the present WLAN hotspot authentication mechanisms isthat the user is required to use the WLAN connection from a separateapplication (either the browser or stand-alone hotspot client) in orderto be allowed to use the hotspot service, before using the e-mailapplication in the above-mentioned example.

There is a user need for automated roaming between Internet AccessPoints; which is also supported in the Nokia platform. In automatedroaming, the application can receive a notification when a morepreferred Internet Access Point within the application's current servicenetwork has become available. The application can then close its currentconnection and reconnect using the newly discovered Internet AccessPoint. In network-level roaming, a middleware component, such as a VPNclient or a mobile IP client manages mobility between underlyingInternet Access Points, transparently to the applications.

Thus, summarizing, the “normal” way for user to gain WLAN access via ahotspot is:

Manual Log-In

-   1. A user reads a sign, showing that there is a hotspot.-   2. User open the browser and tries to browse to a well-known web    page.-   3. The user is redirected to the hotspot provider's web page.-   4. The user is required to enter a user name & password in order to    be authenticated & allowed to access hotspot.

Semi-Automated Mechanism

-   1. User has installed software that has pre-configured    authentication mechanism.-   2. User clicks on software which finds a hotspot.-   3. The user selects a hotspot, which calls an authentication    ‘script’.-   4. The script then authenticates the user to a backend server-   5. The user can then use the hotspot freely.

That is, the user opens a browser when he is inside a hotspot. When theuser attempts to browse to a webpage, the user is re-directed to aportal page. The user can then enter a User Name/Password. Onceauthenticated, the user is able to use the WLAN network. This is inparticular inconvenient for handheld devices (like smart phones) as itrequires the user to be aware of the surrounding wireless networks andperform more steps in order to be connected.

Alternately, some hotspot aggregators use scripts which signal a backendserver, mimicking the web page based login described above. Thesescripts are not completely automated, however, and require user action.

Thus, still some manual input from the user is required in order toconnect and de-connect via a Hotspot. That is, the user of a mobileterminal having WLAN has to first establish a link layer connection andthereafter start the hotspot client in order to be able to use thenetwork connection, e.g., to use the Internet.

Additionally, wireless signals are affected by environmental factors.Walls, for example, can reduce the signal strength of wireless radios.Other wireless networking technologies, such as Bluetooth, can causeinterference with WLAN signals. Therefore, a user might loose or gain awireless connection based upon environmental issues. If a user loses aconnection to the WLAN hotspot because another user happens to use aBluetooth-enabled device, then the WLAN user must perform the stepslisted above to-regain the connection to the WLAN hotspot.

SUMMARY OF THE INVENTION

Hence, it is an object of the present invention to solve the problemmentioned above and to provide support for an easy and automated logonto an access entity such as a WLAN hotspot.

This object is solved by a method for handling a network connection of anetwork device comprising an operation entity for handling networkconnection, wherein at least one access client entity providingconnection handling to a specific network access device is connectableto the operation entity, the method comprising the steps of

-   identifying, by the operation entity, a need for a network    connection,-   requesting the access client entity to perform authentication, and-   performing, by the access client entity, the authentication.

Alternatively, the object is solved by a method for operating anoperation entity for handling network connection, wherein at least oneaccess client entity providing connection handling to a specific networkaccess device is connectable to the operation entity, the methodcomprising the steps of

-   identifying, by the operation entity, a need for a network    connection, and-   requesting the access client entity to perform authentication.

As a further alternative, the above object is solved by a method foroperating an access client entity for handling a network connection to aspecific network access device, connectable to a network devicecomprising an operation entity for handling network connection, themethod comprising the steps of

-   receiving a request from the operation entity to perform    authentication, and-   performing the authentication.

Moreover, the above object is solved by a network device comprising anoperation entity for handling network connection and at least one accessclient entity providing connection handling to a specific network accessdevice, wherein

-   the operation entity is adapted to identify a need for a network    connection and to inform the access client entity, and-   the at least one access client entity is adapted to perform an    authentication.

Alternatively, the above object is solved by an access client entityproviding connection handling for a specific network access device,comprising

-   means for receiving a request to perform authentication from an    operation entity, and-   means for performing the authentication.

Further alternatively, the above object is solved by an operation entityfor handling network connection, the operation entity comprising

-   means for identifying a need for a network connection, and-   means to request an access client entity providing connection    handling for a specific network access device to perform an    authentication.

Hence, according to the invention, the authentication procedure isdelegated to a separate element, namely an access client entity (anexample therefore being a hotspot client). This access client entity canbe specific for a specific network access device, so that no manualinput from the user is required.

Thus, according to the invention, the authentication is integrated intothe connection subsystem.

Hence, the authentication process is simplified allowing anyapplication, such as email, to gain access to the hotspot withoutrequiring additional steps by the user.

According to a further aspect of the invention, the operation entity maybe informed about the result of the authentication by the access cliententity, and, in case the authentication was successful, the operationentity may allow use of the network connection.

According to another aspect of the invention, a plurality of accessclient entities may be provided, and an access client entity of theplurality of access client entities may be selected based on the needfor a network connection.

According to another aspect of the invention, a message may be sent fromthe access client entity to the operating system client to request theoperating system client to notify when a certain connection profilebecomes available. Alternatively, a message may be sent from theoperating system client to the access client entity to request theaccess client entity to notify when a certain connection profile becomesavailable.

According to another aspect of the invention, a message may be sent fromthe operation entity to the access entity client by which the operationentity requests the access client entity to perform the authentication.

According to a further aspect of the invention, a message may be sentfrom the operation entity to the access entity client by which theoperation entity requests the access client entity to perform ade-authentication.

According to another aspect of the invention, a message may be sent fromthe access client entity to the operation entity by which the accessclient entity indicates to the operating system that the authenticationhas been successfully performed.

According to another aspect of the invention, a message may be sent fromthe access client entity to the operation entity by which the accessclient entity indicates to the operating system that de-authenticationhas been successfully performed.

According to a further aspect of the invention, a message may be sentfrom the access client entity to the operation entity by which theaccess client entity indicates to the operating system thatauthentication/de-authentication has failed.

According to another aspect of the invention, a modification of anetwork connection setting by a user input is prohibited.

According to a further aspect of the invention, an access client entityis registered to the operation entity.

According to another aspect of the invention, an access client entity islinked to a profile, wherein in the authenticating step, the operationentity informs the access client entity linked to the profile in case aconnection with the profile is to be established.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is described by referring to the enclosed drawings, inwhich:

FIG. 1 shows a block diagram of the architecture according to anembodiment of the present invention,

FIG. 2 shows a message sequence chart illustrating a registration of ahotspot client according to the embodiment of the present invention,

FIG. 3 shows a message sequence chart illustrating an automatic hotspotlogin according to the embodiment of the present invention,

FIG. 4 shows a message sequence chart illustrating an automatic hotspotlogoff according to the embodiment of the present invention,

FIG. 5 shows a message sequence chart illustrating a WLAN availabilitydiscovery and authentication according to the embodiment of the presentinvention, wherein the hotspot client manages discovery settings,

FIG. 6 shows a message sequence chart illustrating an WLAN availabilitydiscovery and authentication according to the embodiment of the presentinvention, wherein the OS manages discovery settings,

FIG. 7 shows a message sequence chart illustrating an the basicmiddleware enabled hotspot authentication according to the embodiment ofthe present invention in more detail,

FIG. 8 shows a message sequence chart illustrating the WLAN availabilitydiscovery and authentication according to the embodiment of the presentinvention in more detail, and

FIG. 9 shows a message sequence chart illustrating the WLAN hotspotde-authentication according to the embodiment of the present inventionin more detail.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In the following, a preferred embodiment of the present invention isdescribed by referring to the attached drawings.

As described above, currently WLAN hotspot clients are currently usedfor an automated hotspot logon. To allow the implementation of suchclients to operating systems such as Symbian, and to integrate theautomated WLAN hotspot logon with networking of such an operatingsystem, according to the embodiment there is provided

-   a mechanism to delegate the management of WLAN selection (SSID) to a    separate client, and-   a mechanism to integrate a WLAN hotspot client with seamless roaming    and with native user interfaces.

In more detail, according to the present embodiment, the following isprovided:

A WLAN Internet Access Point setting that indicates that the SSIDsettings are managed by an external software entity. When a WLANInternet Access Point setting has been configured with such anindication, the operating system knows that it is not responsible fordetecting the availability of the Internet Access Point. The operatingsystem may also detect that the user should not be able to use thestandard user interfaces to modify the WLAN settings, because WLANsettings are managed by a separate software entity. An embodiment ofthis setting is a special value of the existing SSID field thatindicates an undefined SSID.

Moreover, an Application Programming Interface (API) is defined betweenthe operating system and a 3rd party hotspot client. The API enables thefollowing features:

-   Subsequent installation of a 3rd party hotspot client or several    clients-   Automatic activation of a 3rd party hotspot client (or a    notification to the hotspot client) by the WLAN subsystem or the    operating system when the WLAN subsystem or the operating system    detects a need to log on to a WLAN network discovered by the WLAN    subsystem system-   Capability to deliver notifications of events from the hotspot    client to the WLAN subsystem or the operating system. Notifications    could be given in the following events: discovery of a suitable    network by the hotspot client, successful authentication,    unsuccessful authentication (with various reason codes),    authenticated session terminated, successful log-out, unsuccessful    log-out-   Capability to deliver notifications of events from the WLAN    subsystem or the operating system to the hotspot client.    Notifications could be given in the following events: need to log    in, need to log out.

Implementing roaming decisions or automatic Internet Access Pointselection by the operating system, based on notifications given by a 3rdparty hotspot client. For example, the “link up” notification about aWLAN Internet Access Point should be given to an application only afterthe authentication has been successfully completed, or mobile IPregistration should be tried after successful authentication.

In the following, the principles of the embodiment are described byreferring to FIGS. 1 to 6.

In FIG. 1, an overview of the software architecture is shown, which isprovided in a network device such as a smart phone, laptop, PDA or thelike. Reference numeral 1 denotes a WLAN hotspot client 1 as an examplefor a first access client entity (access client device), and referencenumeral 2 denotes a WLAN hotspot client 2 as an example for a secondaccess client entity (access client device). Reference numeral 3 denotesan Operating System (OS) as an example for an operation entity(operation device), and reference numeral 3 a denotes a WLAN subsystemintegrated in the operating system 3. Reference numeral 4 denotes a WLANhotspot client API.

Preferably, the following features should be available in the API 4.

-   The API should be able to register a 3rd party hotspot client (e.g.,    the WLAN hotspot client 1 and/or 2) to the authentication framework    of the operating system. The hotspot client might be implemented as    a dynamic link library that exports a standard hotspot client    interface. Upon the registration, the operating system learns the    file name of the library, and the operating system will later be    able to call various methods in the hotspot client.-   The API 4 should be able to link a 3rd party hotspot client (e.g.,    the WLAN hotspot client 1 and/or 2) to a profile. This means that    when a connection with the profile is established, the operating    system will call the linked hotspot client to perform    authentication.

In addition, the following primitives should be defined for the API:

-   An API primitive by which the hotspot client can request the    operating system to notify when a certain connection profile becomes    available (used when the operating system manages WLAN network    discovery settings).-   An API primitive by which the operating system can request the    hotspot client to notify when a certain connection profile becomes    available (used when the hotspot client manages WLAN network    discovery settings).-   An API primitive by which the operating system can request the    hotspot client to perform authentication.-   An API primitive by which the operating system can request the    hotspot client to perform de-authentication.-   An API primitive by which the hotspot client can indicate to the    operating system that authentication has been successfully    performed.-   An API primitive by which the hotspot client can indicate to the    operating system that de-authentication has been successfully    performed.-   An API primitive by which the hotspot client can indicate to the    operating system that authentication/de-authentication failed.

In the following, the operation of the operating system and the hotspotclients in connection with the API and the use of the API primitivesmentioned above are described in the following in connection with FIGS.2 to 6.

FIG. 2 shows a message sequence chart of the registration of a hotspotclient, in this example, of the WLAN hotspot client 1. For example, thisregistration procedure may be carried out at the first time the networkdevice connects to the particular hotspot, or beforehand via a websiteof the operator of the hotspot. Alternatively, the registration could becarried out when the hotspot client software is installed. It could beupon the first connection or beforehand. The registration could also bedone as part of the software build process by the manufacturer of thedevice.

The procedure starts with starting the installation program of the WLANhotspot client 2, in which the files needed by the hotspot applicationare installed (step S1). In step S2, a register message “WLAN hotspotclient 1” is sent to the operating system. In turn, the operating systemrecords where the executable for “WLAN hotspot 1” is located and otherconfiguration (step S3). As mentioned above, the hotspot client may beimplemented as a dynamic link library, and upon the registration, theoperating system learns the file name of the library.

After the “WLAN hotspot client 1” has been installed, it is possible toconfigure the operating system's setting for a certain profile to use“WLAN hotspot client 1”. That is, the hotspot client is linked to aprofile, as described above.

FIG. 3 shows a message sequence chart of an automatic hotspot login.

In step S11, the operating system (OS) detects a need to establish aWLAN connection to a network that is configured to use “WLAN hotspotclient 1”. After this, a layer 1 and 2 WLAN connection is established instep S12. In step S13 an Authenticate message is sent to the WLANhotspot client 1. That is, this message is the API primitive by whichthe operating system can request the hotspot client to performauthentication, as described above.

The hotspot client 1 performs, in turn, an automatic login, using, e.g.,HTTP (Hypertext Transfer Protocol), at an access point (not shown) ofthe corresponding hotspot (step S14). In case of a successfulauthentication, the WLAN hotspot client sends an Authentication complete(success) message to the operating system in step S15. This message isthe API primitive by which hotspot client can indicate to the operatingsystem that the authentication has been successfully performed. In caseof an unsuccessful case, the hotspot client 1 would send the APIprimitive described above by which the hotspot client can indicate tothe operating system that the authentication has failed.

After this, the operating system considers the WLAN connection to beavailable and it can be indicated to the application or Mobile IP, forexample (step S16). Thus, a full automatic hotspot login is performed,in which no further manual input from the user is necessary.

FIG. 4 shows a message sequence chart in which an automatic hotspotlogoff is illustrated. An automatic hotspot logoff might be performed inorder to save unnecessary login time or to save resources.

In step S21, the operating system detect that a WLAN connection needs tobe closed. For example, no application is using the connection anymore.Thus, in step S22, it sends a Disconnect message to the WLAN hotspotclient 1. This message is the API primitive mentioned above by which theoperating system can request the hotspot client to perform ade-authentication.

In turn, the WLAN hotspot client 1 performs a logoff protocol, e.g., byusing HTTP (step S23). In case of a successful de-authentication, itsends a De-authentication complete (success) message to the operatingsystem in step S24. This message is the API primitive mentioned above bywhich the hotspot client can indicate to the operating system that thede-authentication has been successfully performed. In case of anunsuccessful de-authentication, the API primitive is sent, by which thehotspot client can indicate to the operating system that thede-authentication has failed.

In step S25, the operating system shuts down the WLAN layer 1 and 2connection (established in step S12 shown in FIG. 3). Thereafter, theWLAN connection is closed.

In FIG. 5, a message sequence chart is shown illustrating a WLANavailability discovery and authentication.

In step S31, the WLAN hotspot client 1 sends a message Register for WLANscanning results to the operating system. This is the API primitivementioned above by which the hotspot client can request the operatingsystem to notify when a certain connection profile becomes available.

In turn, the operating system and the WLAN subsystem (3 a in FIG. 1)perform periodic scanning (step S32). In step S33, the operating systemsends raw WLAN scanning results to the hotspot client. Then, the WLANhotspot client uses its own network discovery settings (e.g., SSIDlists) to detect whether a compatible network is available (step S34).The hotspot client may use additional proprietary means to learn moreabout the WLAN networks. In case of success, the hotspot client sends amessage including an Indication that a compatible WLAN hotspot isavailable to the operating system in step S35. In response to this, theoperating system decides to activate a WLAN hotspot connection with thiscompatible WLAN hotspot in step S36. In step S37, the automatic logon iscarried out, as described above in connection with FIG. 3.

In FIG. 6, also a message sequence chart illustrating a WLANavailability discovery and authentication is shown, however, in thiscase the operating system manages the discovery settings.

In step S41, the operating system and the WLAN subsystem performperiodic scanning. In step S42, the operating system uses its ownnetwork WLAN discovery settings (e.g., SSID lists) to detect that a WLANhotspot profile is available. In this step, the operating system maysend the API primitive described above to the hotspot client by whichthe operating system can request the hotspot client to notify when acertain connection profile becomes available.

In case of success, the operating system decides in step S43 to activatethe WLAN hotspot connection. Thereafter, the automatic logon describedabove in connection with FIG. 3 follows.

Thus, according to the present embodiment, a ‘standard’ API is createdinto the connection mechanism to automate hotspot login. This API isable to call external mechanisms, such has 802.1x mechanisms orproprietary authentication scripts so that users would need to performminimal steps to use hotspots.

This API is tightly integrated into the WLAN connection managementsystem in handhelds.

Hence, it is not necessary for the user to launch specialized softwareseparately to access hotspots, and a common look & feel across multipleservice providers is possible.

In the following, the WLAN hotspot authentication scenarios describedabove are described in more detail by referring to FIGS. 7 to 9.

FIG. 7 shows a message sequence chart illustrating a basic middlewareenabled hotspot authentication.

In principle, this is a more detailed procedure as described above inconnection with FIG. 3. In particular, FIG. 3 shows some more functionsof the operating system, namely the WLAN subsystem, a network subsystemand a bearer manager. The procedure may start when some application orsubsystem initiates a network connection. Then, the network subsystemsends a Connect message to the WLAN subsystem. In this way, the WLANlayer 1 and 2 connection is established (similar to step S12 in FIG. 3).It is noted that before authentication, no IP-level connection up anddata is allowed to flow to application.

The network subsystem selects a profile 1 and sends a message ConnectComplete (profile 1) to the bearer manager, which forwards anAuthentication (profile 1) to the WLAN hotspot client. That is, thismessage is the API primitive by which the operating system can requestthe hotspot client to perform authentication (similar to step S13 inFIG. 3). Thereafter, the WLAN hotspot client performs the authenticationby sending a HTTP request to the network subsystem, which sends a datarequest to the WLAN subsystem, which transmits the data to the hotspot.A corresponding response is received via the WLAN subsystem andforwarded to the network subsystem, which sends a HTTP response to theWLAN hotspot client. This procedure corresponds to step S14 of FIG. 3.It is noted that the authentication by using HTTP is only an example.Moreover, there may be more than only one or two transactions during theauthentication.

In case of a successful authentication, an Authentication complete(success) message is sent to the bearer manager. This is the APIprimitive by which the hotspot client can indicate to the operatingsystem that authentication has been successfully performed (similar tostep S15 in FIG. 3).

After this, a Release connection (profile 1) is sent to the networkingsubsystem in order to release the connection after the successfulconnection. Thereafter, the connection is up and running. Data requestsfrom the application are allowed to the network subsystem.

FIG. 8 shows a message sequence chart illustrating how discovery andauthentication could be combined into a single operation.

The procedure starts when an application registers for connectionavailability regarding one or more profiles (profile 1, profile 2, . . .profile n) with the bearer manager. The bearer manager sends a WLANconnection availability requested indication message to the WLAN hotspotclient. In turn, the WLAN hotspot client may request priorityavailability indications for all the supported connection profiles andsends a corresponding message Register for priority connectionavailability (profile 1, profile 4, . . . ), assuming that profile 1 hasthe highest priority, profile 4 as the second highest priority and soon.

Meanwhile, the WLAN subsystem performs periodic scanning, and send aScan response including a station list. The bearer manager checkswhether a there is a matching WLAN network. In case a matching WLANnetwork is found, a connection availability indication (profile 1) issent to the WLAN hotspot client, assuming that a network correspondingto profile 1 is available. The WLAN hotspot client sends then a Connect(profile 1) to the networking subsystem, so that then a WLANauthentication is performed according to the scheme as shown in FIG. 7.Thereafter, a connection to profile X (e.g., profile 1 as describedabove) available indication is sent to the WLAN hotspot, which sends aConnect (profile X) to the bearer manager.

FIG. 9 shows a message sequence chart illustrating a WLAN hotspotde-authentication.

Similar as described above in connection with FIG. 4, thede-authentication may start when some application or subsystem initiatesa disconnect request to shutdown the connection, for example, when it isdiscovered that the connection is no longer needed.

Thus, the networking subsystem issues a disconnect indication (profile1) to the bearer manager, which sends a Disconnect (profile 1) to theWLAN hotspot client. That is, this is the API primitive by which theoperating system can request the hotspot client to performde-authentication (similar to step S22 in FIG. 4). The hotspot clientperforms the logoff by using HTTP, similar as in the case of performingthe authentication (similar to step S23 in FIG. 4). It is noted thatperforming the de-authentication by using HTTP is only an example.Moreover, there may be more than one or two transactions during thede-authentication.

When the de-authentication has been successful, the WLAN hotspot clientsends a de-authentication complete (success) message to the bearermanager. This is the API primitive by which the hotspot client canindicate to the operating system that the de-authentication has beensuccessfully performed (similar to step S24 in FIG. 4). The bearermanager sends a corresponding message shutdown connection 8profile 1) tothe networking subsystem, which issues a shutdown WLAN connectionmessage to the WLAN subsystem.

Thereafter, the connection is down and no data even at link layer can beexchanged anymore.

Thus, according to the present embodiment, it is possible to implement3rd party hotspot logon clients, which improve the usability of publicWLAN. In particular, the operating system has the knowledge about whichprofiles are available, which networks (SSIDs). This information is usedby the hot spot clients to do the authentication.

That is, according to the embodiment, integration of 3rd party hotspotclients with native user interfaces, automatic connection selection, andseamless roaming are possible.

Hence, this invention enables seamless roaming when there are severalhigher layer (higher than link layer) authentications needed, forexample, when several hotspot clients are used. This is possible due tothe automatic authentication.

In particular when a WLAN hotspot client is implemented on a mobiledevice, such as a Symbian phone, the following advantages are achievedaccording to the invention:

-   A 3rd party application is enabled to manage its own WLAN settings,    compatibly with the existing WLAN Internet Access Point definition.    The existing middleware should be able to detect when a WLAN hotspot    connection is available.-   WLAN hostspot clients are integrated with the device's connection    selection user interfaces, with automatic Internet Access Point    selection and with seamless roaming.-   the user does not need to run a hotspot client separately before    running the actual application that the user wants to use. Instead,    the hotspot application can be run automatically when needed.

The invention is not limited to the embodiment described above, andvarious modifications are possible.

For example, the invention is not limited to WLAN, but can also beapplied to other connection networks such as Bluetooth, WiMAX and thelike in which it is possible to connect to different access entitieswhich may have different profiles and it is necessary to perform anauthentication. That is, the access client (hotspot client) could be anyauthentication client that performs an authentication task before theconnection is “released” to other applications.

Moreover, it is not even necessarily restricted to radio networks, it isalso applicable to wired networks, when a connection to an networkaccess entity is achieved via a wired access point by using a cable(such as a LAN connection or the like). In this case, differentspecifications of the wired access point can be considered by usingdifferent access clients. For example, the present invention can beapplied to xDSL or other wired broadband connections.

Moreover, in the above description of the preferred embodiment, the“hotspot” is only an example for a network access entity. That is, alsoother forms of a network access entity are possible.

Furthermore, according to the embodiment described above, the WLANhotspot client (as an example for an access client entity) and theoperating system (as an example for an operation entity) are implementedas software within a computer running the network device. However, theaccess client entity and the operation entity may also be realized ashardware such as ASICs, DSPs or the like, so that different accessclient entities may also be replaced or used by inserting correspondingcomponents into a suitable socket or the like of the network device.

1. (canceled)
 2. A method, comprising: operating an operation entity forhandling network connection, wherein at least one access client entityproviding connection handling to a specific network access device isconnectable to the operation entity, identifying, by the operationentity, a need for a network connection, and requesting the accessclient entity to perform authentication.
 3. A method, comprising:operating an access client entity for handling a network connection to aspecific network access device, connectable to a network devicecomprising an operation entity for handling network connection,receiving a request from the operation entity to perform authentication,and performing the authentication.
 4. (canceled)
 5. The method accordingto claim 2, wherein a plurality of access client entities is provided,and the identifying step comprises the step of selecting an accessclient entity of the plurality of access client entities based on theneed for a network connection.
 6. The method according to claim 2,wherein a message is sent from the access client entity to the operatingsystem client to request the operating system client to notify when acertain connection profile becomes available.
 7. The method according toclaim 2, wherein a message is sent from the operating system client tothe access client entity to request the access client entity to notifywhen a certain connection profile becomes available.
 8. The methodaccording to claim 2, wherein a message is sent from the operationentity to the access entity client by which the operation entityrequests the access client entity to perform the authentication.
 9. Themethod according to claim 2, wherein a message is sent from theoperation entity to the access entity client by which the operationentity requests the access client entity to perform a de-authentication.10-12. (canceled)
 13. The method according to claim 2, furthercomprising prohibiting a modification of a network connection setting bya user input.
 14. The method according to claim 2, further comprisingregistering an access client entity to the operation entity.
 15. Themethod according to claim 2, further comprising linking an access cliententity to a profile, wherein in the authenticating step, the operationentity informs the access client entity linked to the profile in case aconnection with the profile is to be established. 16-28. (canceled) 29.A device, wherein the device is configured to provide connectionhandling for a specific network access device, comprising a receiverconfigured to receive a request to perform authentication from anoperation entity, and a performer configured to perform theauthentication.
 30. (canceled)
 31. The access client entity according toclaim 29, further comprising means for sending a message to theoperation entity to request the operation entity to notify when acertain connection profile becomes available.
 32. The device accordingto claim 29, further comprising a receiver configured to receive amessage requesting the device to notify when a certain connectionprofile becomes available.
 33. The entity device according to claim 29,further comprising a receiver configured to receive a message by whichthe entity device is requested to perform the authentication.
 34. Thedevice according to claim 29, further comprising a receiver configuredto receive a message by which the access client entity is requested toperform a de-authentication. 35-37. (canceled)
 38. The device accordingto claim 29, further comprising a registering unit configured toregister to the operation entity.
 39. A device, wherein the device isconfigured to handle network connection, comprising an identify unitconfigured to identify a need for a network connection, and a requestunit configured to request an access client entity providing connectionhandling for a specific network access device to perform anauthentication.
 40. (canceled)
 41. The device according to claim 39,further comprising a selector configured to select an access cliententity of a plurality of access client entities based on the need for anetwork connection.
 42. The device according to claim 39, furthercomprising a receiver configured to receive a message requesting tonotify when a certain connection profile becomes available.
 43. Thedevice according to claim 39, further comprising a sender configured tosend a message to the access client entity requesting to notify when acertain connection profile becomes available.
 44. The device accordingto claim 39, further comprising a sender configured to a message to theaccess client entity requesting the access client entity to perform theauthentication.
 45. The device according to claim 39, further comprisinga sender configured to send a message to the access client entityrequesting the access client entity to perform a de-authentication.46-48. (canceled)
 49. The operation entity according to claim 39,further comprising a prohibiting unit configured to prohibit amodification of a network connection setting by a user input.
 50. Theoperation entity according to claim 39, further comprising registrationunit configured to register an access client entity.
 51. The deviceaccording to claim 39, further comprising a link unit configured to linkan access client entity to a profile, wherein the device is configuredto inform the access client entity linked to the profile in case aconnection with the profile is to be established.
 52. A computer programproduct embodied on a computer readable medium, the computer programcomprising program code for controlling a computer to perform: operatingan operation entity for handling network connection, wherein at leastone access client entity providing connection handling to a specificnetwork access device is connectable to the operation entity,identifying, by the operation entity, a need for a network connection,and requesting the access client entity to perform authentication.53-54. (canceled)
 55. A computer program product embodied on a computerreadable medium, the computer program comprising program code forcontrolling a computer to perform: operating an access client entity forhandling a network connection to a specific network access device,connectable to a network device comprising an operation entity forhandling network connection, receiving a request from the operationentity to perform authentication, and performing the authentication. 56.A device, comprising: means for operating an operation entity forhandling network connection, wherein at least one access client entityproviding connection handling to a specific network access device isconnectable to the operation entity, means for identifying a need for anetwork connection, and means for requesting the access client entity toperform authentication.
 57. A device, comprising: means for operating anaccess client entity for handling a network connection to a specificnetwork access device, connectable to a network device comprising anoperation entity for handling network connection, means for receiving arequest from the operation entity to perform authentication, and meansfor performing the authentication.
 58. The method according to claim 3,wherein a plurality of access client entities is provided, and theidentifying comprises selecting an access client entity of the pluralityof access client entities based on the need for a network connection.59. The method according to claim 3, wherein a message is sent from theaccess client entity to the operating system client to request theoperating system client to notify when a certain connection profilebecomes available.
 60. The method according to claim 3, wherein amessage is sent from the operating system client to the access cliententity to request the access client entity to notify when a certainconnection profile becomes available.
 61. The method according to claim3, wherein a message is sent from the operation entity to the accessentity client by which the operation entity requests the access cliententity to perform the authentication.
 62. The method according to claim3, wherein a message is sent from the operation entity to the accessentity client by which the operation entity requests the access cliententity to perform a de-authentication.
 63. The method according to claim3, further comprising: prohibiting a modification of a networkconnection setting by a user input.
 64. The method according to claim 3,further comprising: registering an access client entity to the operationentity.
 65. The method according to claim 3, further comprising: linkingan access client entity to a profile, wherein in the authenticatingstep, the operation entity informs the access client entity linked tothe profile in case a connection with the profile is to be established.